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(54) Transaction networks 



(57) A transaction network (30 or 60) comprises a 
plurality of terminals, for example an ATM (50 or 62), 
Each terminal (50 or 62) comprises a plurality of periph- 
erals (52 or 64) such as a user interface (64d), card 
reader (64a), receipt printer (64b) and cash dispenser 
(64c). The application software for the peripherals (52 
or 64) is held in a central server (34) located externally 
of the terminal (52 or 62) and linked to each peripheral 



(52 or 64) by a communication link (33,54,55, or 71). 
The link (33,54,55, or 71) extends to the individual pe- 
ripherals (52 or 64) so that each peripheral is a direct 
client of the server (34). 

Additionally the individual peripherals (52 or 64) are 
connected to each other over the link (33,54,55 or 71) 
to enable them to communicate directly with each other 
on a peer-to-peer basis. A banking information data- 
base (legacy Host) (1 2) is connected to the server (34). 
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Description 

[0001] This invention relates to transaction networks. 
In particulate invention relates to self service terminal 
(SST) transaction networks such as automated teller 
machine (ATM) transaction networks. The invention al- 
so relates to terminals for use in transaction networks, 
and to peripheral devices for use in such terminals. 
[0002] Transaction networks comprise one or more 
transaction terminals connected to a server. Typical 
transaction networks may be used to provide banking 
or retail services. A typical transaction terminal may be 
an SST (one type of SST being an ATM, another type 
of SST being a retail point-of-sale (PoS) terminal, yet 
another type of SST being a financial services centre 
(FSC)). Fig 1 shows part of a prior art ATM network 10 
in which an information database 12 (termed a legacy 
host) is connected to a server 14 by a communication 
cable 16. The server 14 is also connected to a terminal 
18 having a central processor 20, typically PC-based, 
which controls the application flow (the order in which 
events may occur) and the associated user interface 
presentation for the terminal 18. Application software 
and the graphics, animation and sound files used by the 
application software are stored on a hard disk 21 or oth- 
er mass storage device within the terminal 18. 
[0003] The network 10 is shown having one terminal 
18, however, a plurality of other terminals, which may 
be of the same or of a different kind (ATM, PoS terminal, 
FSC, or such like), may also be connected to the server 
14. Simple client-server transactions are conducted be- 
tween terminal 18 and the host 12 for obtaining specific 
customer information used in the processing of a cus- 
tomer's transaction. In the case of an ATM the transac- 
tion may typically be a cash withdrawal or a balance re- 
quest. In the case of a retail PoS terminal a typical trans- 
action is a price lookup. 

[0004] Terminal 1 8 includes peripheral devices 22 (re- 
ferred to hereinafter as "peripherals') that are typically 
very specific to the function of the terminal 18. Typical 
peripherals included in an ATM are a card reader, a cash 
dispenser, a receipt printer and an encrypting keyboard. 
These devices must be provided with appropriate con- 
trol software and require some form of embedded 
processing capability to conduct communications with 
the central processor 20 and to implement commands 
received therefrom. 

[0005] The above architecture (as shown in Fig 1 ) has 
a number of disadvantages. The main task of the central 
processor 20 is to present information, graphics and an- 
imation to the user. However the processor 20 is also 
required to conduct control and possibly maintenance 
operations on the peripherals 22 connected to it. To ob- 
tain a high level of user interface performance, proces- 
sor 20 must be very powerful because the processor 20 
has to allocate some of its processing power for control- 
ling the operation of the peripherals 22. 
[0006] The peripherals 22 act as simple command 



processing systems, with all application control being 
conducted from the central processor 20. Th is is despite 
the fact that each peripheral 22 usually has an embed- 
ded processor. Thus, peripheral processing capability is 

5 not well utilised. 

[0007] It is an object of the invention to provide a 
transaction network which obviates or mitigates one or 
more of the above disadvantages. 
[0008] According to a first aspect of the invention a 

10 transaction network comprises a server and at least one 
terminal, each terminal having a plurality of peripherals, 
the network being characterised in that the server is ar- 
ranged to store software for the peripherals, and com- 
munication links are provided from the server to each 

15 peripheral, whereby each peripheral is operable to 
download software from the server. 
[0009] Preferably, each peripheral is operable to con- 
figure itself using the downloaded software. Preferably, 
the software is downloaded directly from the server. 

20 [0010] By virtue of the present invention each periph- 
eral has direct and independent access to the server. 
By enabling each peripheral to download software di- 
rectly from the server and thereby to configure itself, 
each peripheral can operate autonomously. This means 

25 that in a transaction terminal containing such autono- 
mous peripherals no central processor is required 
(which in prior art terminals controls the operation of the 
peripherals) nor is a mass storage device required 
(which in prior art terminals stores software required by 

30 the peripherals). Each peripheral is a direct client of the 
server. 

[0011] Preferably, the software stored on the server 
includes application software and peripheral driver soft- 
ware. 

35 [0012] Each peripheral has its own embedded proc- 
essor which operates with the communication links to 
download software from the server. 
[0013] Each peripheral includes hardware control 
means to control the hardware of the peripheral, and the 

40 embedded processor may operate the hardware control 
means in a manner determined by the downloaded soft- 
ware. 

[0014] The software stored for each peripheral may 
be independent of the software for each of the other pe- 

45 ripherals so that each peripheral can download software 
relating only to that peripheral (i.e. itself) ; thus, the soft- 
ware may comprise a plurality of independent software 
modules, so that each peripheral may download only the 
software module or modules required by that peripheral. 

so For example, a card reader peripheral would not down- 
load software modules relating to a receipt printer. 
[0015] Preferably, each peripheral stores download- 
ed software in volatile memory. Conveniently, the vola- 
tile memory is DRAM or SRAM. 

55 [0016] Preferably, each peripheral has a non-volatile 
memory for storing boot-up information, whereby, on 
powering the peripheral, the contents of the non-volatile 
memory may be used for initialising the peripheral. Con- 
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veniently, the non-volatile memory is FLASH EPROM. 
[0017] The term communication links relates to com- 
munication hardware within each peripheral (peripheral 
communication hardware), communication hardware 
within the server (server communication hardware), and 5 
a communication medium over which the peripheral and 
server communication hardware communicate. The 
communication medium may be physical, such as a ca- 
ble; or it may be non -physical, such as the atmosphere. 
The communication medium may comprise intercon- io 
nected. cables and routers to provide a connection be- 
tween the peripheral and server communication hard- 
ware. 

[0018] Preferably, the peripheral communication 
hardware is an ethernet card having a unique ethernet 15 
card address (a media access control [MAC] address). 
On powering up, each peripheral boots-up using the 
non-volatile memory to initiate a network session with 
the server. Software modules required by that peripheral 
(such as application software and/or operating system 20 
software) are then transmitted from the server to that 
peripheral. 

[0019] Preferably, the peripherals communicate with 
the server using the TCP/IP protocol. Preferably, during 
the boot-up process the embedded processor initiates 25 
a network session with the server by sending the ether- 
net card MAC address associated with the processor to 
the server with a message to indicate that the peripheral 
has just powered-up and requires an IP address. Con- 
veniently, this is implemented using the BOOTP proto- 30 
col so that the peripheral broadcasts its MAC address 
to every device on the network; and the server responds 
by supplying an IP address to the peripheral using ad- 
dress resolution protocol (ARP) and a dynamic host 
configuration protocol (DHCP). 35 
[0020] Preferably, the communication links also ena- 
ble the peripherals in a terminal to communicate with 
each other. This communication may be direct and on 
a peer-to-peer basis. 

[0021] The peripherals may be selected from the fol- 40 
lowing non-exhaustive list of peripherals, namely: a user 
interface, a reader, a receipt printer and a cash dispens- 
er. The reader may be a card reader for reading from 
and writing to magnetic stripe cards and/or Smart cards. 
Alternatively or additionally, the reader may be a Smart 45 
device reader for reading from and writing to devices 
such as Smart buttons, rings, and such tike. 
[0022] The communication links may be dedicated 
links, i.e. the links may be used exclusively for connect- 
ing the server to the terminal (for example, the commu- so 
nication links may be part of a LAN or a WAN). Alterna- 
tively they may comprise a modem and information sig- 
nal transfer means for enabling transfer of signals from 
the modem through a public telephone network to a 
server. 55 
[0023] Preferably, the communication links include a 
router for providing a single link to the server. One ad- 
vantage ol using a router is that data from the peripher- 



4 

als may be concentrated onto a single link; another ad- 
vantage is that the router can ensure that communica- 
tions between peripherals in the terminal are not trans- 
mitted to the server. 

[0024] In embodiments of the invention there may be 
provided an information database (such as a banking or 
retail database) in communication with the server. 
[0025] According to a second aspect of the invention 
a transaction terminal includes a plurality of peripherals, 
the terminal being characterised in that each peripheral 
has communication hardware for connecting to a server, 
whereby, in use, each peripheral is operable independ- 
ently to access the server and to download software 
therefrom. 

[0026] Preferably, the software is downloaded directly 
from the server to the embedded processor. Thus, the 
software is resident on the server until such time as the 
embedded processor requests the software; it is then 
downloaded by the processor to its associated volatile 
memory. The software is not resident for an extended 
period of time on a storage device located within the ter- 
minal but outside the peripheral. 
[0027] The peripheral communication hardware may 
be in the form of an ethernet card. The ethernet card 
may implement the TCP/IP protocol. 
[0028] According to a third aspect of the invention a 
transaction network system comprises a server and at 
least one terminal, each terminal containing a plurality 
of peripherals, the network system being characterised 
in that the server is arranged to store a plurality of inde- 
pendent software modules, where at least one software 
module is associated with each peripheral, and commu- 
nication links are provided from the server to each pe- 
ripheral, whereby each peripheral is operable to down- 
load one or more of the independent software modules 
from the server and to configure itself using the one or 
more downloaded software modules. 
[0029] According to a fourth aspect of the invention 
there is provided a transaction terminal including a plu- 
rality of modular elements that intercommunicate 
through a sub-network using a network protocol, and a 
router that concentrates communications between the 
modular elements and a remote server through a single 
connection to the server. 

[0030] Preferably, the modular elements are periph- 
eral devices, and the network protocol used is the TCP/ 
IP protocol. 

[0031] According to a fifth aspect of the invention 
there is provided a peripheral device for use in a trans- 
action terminal, the device including a dedicated proc- 
essor, memory, and a port for receiving and sending in- 
formation, whereby the device is configured for installing 
software by downloading the software from a remote 
server over a connected network using a remotely exe- 
cuting Dynamic Host Control Protocol service. 
[0032] The peripheral device may include a web serv- 
er facility for use with a remote terminal implementing a 
web browser facility, thereby providing remote state of 
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health and diagnostic facilities. 
[0033] According to a sixth aspect of the invention 
there is provided a transaction terminal comprising a 
plurality of networked peripheral devices each having 
its own data processor controlling operations of the de- 
vice through execution of software modules download- 
ed to the device via a connected network. 
[0034] The software modules may be applets. 
[0035] According to a seventh aspect of the invention 
there is provided a transaction network system compris- 
ing a server and at least one terminal, each terminal con- 
taining a plurality of peripherals, the network system be- 
ing characterised in that the server is arranged to store 
a plurality of independent software modules, where at 
least one software module is associated with each pe- 
ripheral, and communication links are provided from the 
server to each peripheral, wherein the server is operable 
to reset the peripherals and download software modules 
to the peripherals after they power up. 
[0036] This provides remote, centralised updating of 
the software modules used by the peripherals. A net- 
work administrator only has to update the modules 
stored on the server and instruct the server to re-boot 
the peripherals. When the peripherals re-boot, the newly 
installed software modules will be downloaded to the pe- 
ripherals. 

[0037] In the drawings, 

[0038] Fig 1 is a block diagram of a prior art ATM- 
based transaction network. 

[0039] Embodiments of the invention will now be de- 
scribed, by way of example, with reference to the rest 
of the accompanying drawings in which: 

Fig 2 is a block diagram of a transaction network 
according to one embodiment of the invention; 
Fig 3 is a block diagram of a transaction network 
according to another embodiment of the invention, 
showing a router connecting four peripherals in a 
terminal to a server; 

Fig 4 is a block diagram showing one of the periph- 
erals of Fig 3 in greater detail; and 
Fig 5 is a flowchart relating to one of the peripherals 
of Fig 3. 

[0040] Referring to Fig 2, there is shown therein a 
transaction network 30 including a legacy host 12, a 
server 34 and an ATM 50. The server 34 is very similar 
to server 14, the main difference being that server 34 
stores software modules (such as application software 
and operating system software) for use by peripherals 
within the ATM 50. The ATM 50 has three peripherals 
52, each having communications hardware 54. The 
communications hardware 54 in each peripheral 52 is 
directly connected to a communication port 33 in the 
server 34 by a separate communication medium 55 in 
the form of a data cable. The hardware 54, medium 55, 
and port 33 together form a communication link, so that 
each peripheral 52 has a separate communication link. 



However, having separate cables 55 connecting the 
server 34 to the peripherals 52 may be undesirable be- 
cause of the proliferation of cables that would result from 
increasing the number of peripherals. 

s [0041] Fig 3 is a block diagram of an ATM transaction 
network 60 in accordance with another embodiment of 
the invention. ATM network 60 includes an ATM 62 
which contains four peripherals 64: a card reader 64a, 
a receipt printer 64b, a cash dispenser 64c, and a user 

10 interface 64d. 

[0042] Each peripheral 64 has a network interface 66 
(in the form of an ethernet card, see Fig 4) which is phys- 
ical ly connected to a multiport router 68 by a network 
cable 70. The router 68 receives data on each of the 

15 cables 70 (from the peripherals 64) and concentrates 
this data onto a single cable 72 for transmission to the 
communication port 33 in the server 34. The communi- 
cation port 33, ethernet cards 66, router 68, network ca- 
bles 70, and cable 72 together form a sub-network 71 

20 to which the peripherals 64 and the server 34 are con- 
nected. The sub-network 71 implements the TCP/IP 
protocol and allows open standard connection between 
each peripheral 64 and the server 34, and also between 
different peripherals (e.g. 64a and 64b). Sub-network 71 

25 thereby provides a communication link between a pe- 
ripheral 64 and the server 34. Thus, there is a commu- 
nication link for each peripheral 64, whereby each pe- 
ripheral 64 is able to download software directly from 
the server 34. 

30 [0043] Although the peripherals 64 are connected to 
the server 34 via the router 68, each peripheral 64 has 
independent access to the server 34 and is operable to 
download software modules directly therefrom (i.e. soft- 
ware modules are not first downloaded to an intermedi- 
ns ate location and then copied to the peripherals 64 from 
the intermediate location). The router 68 does not store 
any software modules being downloaded, it merely fa- 
cilitates downloading by managing the communication 
between the server 34 and the peripheral 64 which is 
40 downloading the software. It will be appreciated that the 
flow of information is two-way, a peripheral 64 being op- 
erable to transmit information to the server 34. It will also 
be appreciated that the ATM 62 has no mass storage 
device for permanently storing the downloaded soft- 
45 ware: all downloaded software is stored in memory. In 
this embodiment volatile memory is used; however, in 
an alternative embodiment non-volatile memory could 
cache downloaded software for immediate access on 
power-on with software updates being applied via the 
50 download process described. 

[0044] Each type of peripheral (e.g. a card reader 
64a) needs a different software module (or modules) to 
other types of peripherals (e.g. a receipt printer 64b); 
however, all peripherals of one type (e.g. all card read- 
55 ers 64a) need the same set ol software modules. There- 
fore the server 34 stores a set of software modules for 
each type of peripheral (e.g. 64a) in the network 60; 
where a set of software modules may contain one or 



1/14/05, EAST Version: 2.0.1.4 



7 )- EP 0 953 946 A2 8 



more software modules. 

[0045] Fig 4 shows a block diagram of one of the pe- 
ripherals 64 of Fig 3. The peripheral 64 has an ethernet 
card 66 (which is the peripheral communication hard- 
ware) having a unique MAC address. The ethernet card 
66 implements the TCP/IP protocol, and is in electronic 
communication with an embedded processor 74. Proc- 
essor 74 executes JAVA® code, and communicates with 
peripheral-specific control electronics 76 which controls 
the hardware 78 in the peripheral 64. For a card reader 
peripheral 64a, the hardware 78 includes the card trans- 
port mechanism and the magnetic stripe reader. The 
processor 74 also has associated volatile memory 80 in 
the form of DRAM and non-volatile memory 82 in the 
form of FLASH EPROM. 

[0046] When a peripheral 64 is first powered-up, it re- 
quires an IP (internet protocol) address. IP addresses 
are supplied by the server 34 which implements an ARP 
(address resolution protocol) and DHCP (dynamic host 
control protocol) service for allocating an IP address to 
each peripheral 64 which is connected to the sub-net- 
work 71 . DHCP is a standard protocol which provides a 
way of dynamically allocating IP addresses to proces- 
sors in a network. A range of IP addresses is assigned 
to the DHCP and each processor is configured to re- 
quest an IP address from the DHCP server. The request 
and grant process uses a lease concept with a control- 
lable time period for the lease. 

[0047] When a peripheral 64 is first powered-up, its 
processor 74 uses FLASH EPROM 82 to boot-up and 
broadcast a message requesting an IP address. The 
broadcast message contains the peripheral's MAC ad- 
dress and a special "broadcast address" , which is 
"255.255.255.255". This broadcast address is a stand- 
ard feature of the BOOTP protocol; it means, transmit 
to every device on the sub-network 71 that a peripheral 
with enclosed MAC address req uires an I P address. The 
server 34 receives this broadcast message; allocates 
an available IP address; and sends a grant message to 
the peripheral which requested the IP address (using 
the peripheral's MAC address), where the grant mes- 
sage contains the peripheral's IP address and the serv- 
er's IP address. 

[0048] The newly-powered-up peripheral 64 receives 
this grant message and now knows its IP address and 
the server's IP address. Using this information the pe- 
ripheral 64 can access the server 34 and download an 
operating system using a simple protocol such as TFTP 
(Trivial File Transfer Protocol). Once the peripheral has 
downloaded an operating system (in this embodiment 
JAVA® OS) it can store this operating system in the 
FLASH EPROM 82. This has the advantage that when 
the peripheral 64 is powered-up again it can load the 
operating system directly from the EPROM 82; however, 
the peripheral 64 will still need to obtain an IP address 
from the server 34 using BOOTP 
[0049] When the peripheral 64 has received its IP ad- 
dress and its operating system, it can then use the TCP/ 



IP protocol to download its application software module 
from the server 34 to the volatile memory 80. 
[0050] One advantage of using router 68 is that the 
router 68 can auto-detect how much bandwidth the eth- 

s ernet card 66 within each peripheral 64 requires (for ex- 
ample, whether it requires 10Mbytes per second or 
1 0OMbytes per second). Most of the peripherals, for ex- 
ample, card reader 64a, receipt printer 64b, and cash 
dispenser 64c only receive large amounts of information 

10 (software) when they are downloading software mod- 
ules; at other times they only send or receive small 
amounts of information; thus, these peripherals 64a,b, 
c can operate on a low bandwidth channel (10Mbytes 
per second). However, the user interface peripheral 64d 

75 frequently downloads large amounts of information to 
update the display; so peripheral 64d operates using a 
high bandwidth channel (100Mbytes per second). 
[0051] Another advantage of using a router 68 is that 
the router 68 may ensure that any messages which are 

20 sent by one peripheral (e.g. 64a) within the ATM 62 to 
another peripheral (e.g. 64b) within the same ATM 62 
are not transmitted to the server 34 or to any other ter- 
minal in the network 60. This reduces the amount of traf- 
fic on the network 60 without adversely affecting com- 

25 munication between peripherals 64. 

[0052] When a peripheral 64 has downloaded all nec- 
essary software modules from the server 34 then it is 
ready for use by the terminal 62. The terminal 62 may 
use one of a number of possible application architec- 

30 tures. For example, in one architecture a master/slave 
relationship exists, where the user interface peripheral 
64d is the master and the other peripherals 64a, b,c are 
the slaves. The user interface 64d controls the applica- 
tion flow and instructs the other peripherals 64a, b,c to 

35 carry out specific tasks (e.g. the card reader may be in- 
structed to read a card, the receipt printer may be in- 
structed to print a receipt) as required. The user inter- 
face 64d issues commands over the sub-network 71 us- 
ing TCP/IP. 

40 [0053] In an alternative architecture a peer to peer re- 
lationship exists between the peripherals 64a,b,c ( d so 
that the peripherals 64 send message objects to each 
other to inform one another when significant application 
events occur. The peripherals 64 thereby operate in re- 

45 sponse to one another. 

[0054] One advantage of the invention is that software 
upgrades are easily ach ieved by upgrading the software 
held on server 34 and restarting the peripherals 64 ei- 
ther directly at ATM 62 or via server 34. This allows for 

so the remote administration of the entire transaction net- 
work 60 (which may include a large number of ATMs). 
[0055] The ability of peripherals 64 within an ATM 62 
to dynamically load required software modules provides 
for an efficient and easily controllable mechanism for 

55 supporting the required functionality. For example, if 
card reader 64a is to recognise different types of Smart 
card and standard magnetic stripe cards then card read- 
er 64a requires different software drivers depending on 
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which type of card is inserted into the card reader 64a. 
These software drivers must be available and accessi- 
ble to support the different types of electrical interfaces, 
data streams and communications protocols for each 
type of card. $ 
[0056] By allowing the card reader 64a to download 
software modules from the server 34 as and when re- 
quired the card reader 64 can load software modules 
during operation. Thus, if a user inserts a Smart card, 
and the card reader 64a is currently configured for a 
magnetic stripe card (i.e. the card reader 64a has down- 
loaded software driver modules for a magnetic stripe 
card), then the card reader 64a on detecting that the in- 
serted card is a certain type of Smart card will download 
the relevant software module for use in processing that 
type of Smart card, as will be described with reference 
to Fig 5. 

[0057] The flow chart of Fig 5 illustrates the steps 1 00 
implemented by a card detection software module for 
recognising two types of Smart card. On powering-up, 
the card reader 64a will download this card detection 
software module and also a card driver software mod- 
ule, which by default is the software module for a mag- 
netic stripe card. The ATM 60 then waits for a card to be 
inserted. 

[0058] On detecting that a card is being inserted into 
card reader 64a the card detection software module pro- 
vides for the required electro-mechanical operation to 
receive the card (e.g. the opening of shutters and the 
energising of drive motors as required) and then identi- 
fies the type of card that has been inserted in accord- 
ance with the flow chart of Fig 5. 
[0059] Conventional ATMs which can read more than 
one type of card require all of the necessary software 
driver modules for the types ol card which can be read 
to be available at all times during operation of the ATM. 
This is implemented by the ATM storing all of the re- 
quired software driver modules locally. However, in ATM 
62 it is only necessary to store the card detection soft- 
ware module because the required software driver mod- 
ule can be downloaded when it is needed. 
[0060] The card detection software module recognis- 
es only two types of Smart card; however, if it is desired 
to support additional types of card then the card detec- 
tion software module only needs to be increased in size 
by a small amount sufficient to support the extra deci- 
sion block and card type identification. Conversely, a tra- 
ditional card reader would need to have its program in- 
creased by the total size of the routines required to proc- 
ess the extra type of card or application embedded in 
the card. Similar considerations apply to other modules 
such as the receipt printer 64b and the cash dispenser 
64c. 

[0061] Referring to Fig 5, the card detection software 
module awaits insertion of a card (step 102). Once a 
card has been inserted, the software detects the card 
and determines if the card is a type one Smart card (step 
104). If the card is a type one Smart card then the proc- 



essor 74 (see Fig 4) downloads a type one software driv- 
er module (step 1 06) from the server 34. When the type 
one software has been successfully downloaded the 
ATM 62 (see Fig 4) processes the transaction. 
[0062] If the card is not a type one Smart card then 
the software determines if the card is a type two Smart 
card (step 1 08). If the card is a type two Smart card then 
the processor 74 (see Fig 4) downloads a type two soft- 
ware driver module (step 110). When the type two soft- 
ware has been successfully downloaded the ATM 62 
(see Fig 4) processes the transaction. 
[0063] If the card is neither a type one nor a type two 
Smart card then the software module assumes that the 
card is a magnetic stripe card and uses (step 112) the 
magnetic stripe card driver software module (which in 
this embodiment is downloaded as the default driver). 
The ATM 62 (see Fig 4) then processes the transaction. 
[0064] In the embodiment of Fig 3, the server 34 may 
provide Internet or Intranet access, thereby allowing the 
receipt printer 64b to load Web pages from the server 
34, in addition to loading the appropriate printer driver 
software modules needed to support the graphics, fonts 
and other imagery in the downloaded Web pages. Such 
software modules may be resident in server 34 and 
loaded to the printer 64b only as and when required. 
These software modules consist of code and data, so it 
is possible to load individual graphic imagery, along with 
its own printer driver software, for customising receipts, 
statements and the like. It may be desirable to custom- 
ise receipts and/or statements to promote a certain 
product or brand, or for tailoring the receipt to the user. 
These graphic images are transitory: taking up memory 
space in the printer module 64b only for the duration of 
their task (i.e. until they have been used by the compu- 
ter). 

[0065] Since each peripheral 64 has an independent 
connection to server 34 through a communication link, 
the peripheral 64 can communicate directly and inde- 
pendently with the server 34 not only to download soft- 
ware modules therefrom, but also to obtain data specific 
to a current transaction while the transaction is taking 
place. For example a request may be made for informa- 
tion specific to the user and appropriate to conduct the 
current transaction. Thus, cash dispenser 64c may re- 
quire the user's current balance for determining if the 
user has sufficient funds for a requested cash withdraw- 
al. User interface 64d may require account balance and 
bank statement information for presenting to the user. 
[0066] Since each peripheral in ATM 62 is individually 
connected to server 34 the latest version of a particular 
software module can be made available to all ATMs in 
the network 60 by loading the new version of the soft- 
ware module into the server 34. This does not require 
physical access to any of the terminals in the network 
60. In addition, terminal-specific software modules can 
be made available at the server 34. Such terminal-spe- 
cific software modules may comprise marketing mes- 
sages for display at the ATM 62. 
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[0067] By having a direct connection Irom the periph- 
erals 64 to the server 34 it is possible to allow the pe- 
ripheral software applications to take a more active role 
in the overall operational flow of the ATM 62. This allows 
the user interface processor to concentrate on its prima- 
ry task of providing user interface display graphics, an- 
imation and video facilities. The processing power re- 
quired to operate individual peripherals 64 can then be 
selected to optimise the cost/performance ratio. 
[0068] It is desirable to monitor the operation of the 
peripherals 64 and for this purpose various logs and 
hardware tallies can be provided for. The embedded 
processor 74 (see Fig 4) in a peripheral 64 can be ar- 
ranged to generate such logs and tallies for use with an 
embedded Web server for reporting the results. Access 
points can be provided over the network 60 to allow for 
diagnostic operations including the downloading of 
monitoring information. The reports can be in HTML 
form thus allowing a standard Web browser to access 
the information. 

[0069] Various modifications may be made to the 
above described embodiments. For example, in other 
embodiments, an ATM may be used as a general multi- 
media dispenser, where the media to be dispensed 
ranges from paper (in the form of currency notes, tickets, 
and books of stamps) to plastics media (such as ski 
passes). This requires the ability to dispense media 
types having different dispensing characteristics (such 
as timing and control parameters). Appropriate software 
modules can be readily downloaded by a media dis- 
penser from a server at run time without the need to 
store every possible driver software module in the ter- 
minal housing the dispenser. In other embodiments, a 
different network protocol (such as an RS-232-based 
protocol) and different boot-up protocols may be used. 
[0070] In other embodiments, a different network ar- 
chitecture to that shown for sub-network 71 may be 
used, for example the router function may be imple- 
mented by one of the peripherals such as the user in- 
terface so that the user interlace has a dual port ar- 
rangement: one port for connecting to cable 72 and an- 
other port for connecting to the other peripherals (e.g. 
card reader 64a, receipt printer 64b, cash dispenser 
64c) optionally via a concentrator. This may be used to 
provide the user interlace with a high bandwidth con- 
nection to the server 34 for application and graphics 
download; whereas, the other peripherals (64a,b,c) op- 
erate at a lower bandwidth. The routing functions may 
be implemented in software. Both ports may include eth- 
ernet cards for providing a network connection; alterna- 
tively, the port connected to the server 34 may use a 
modem for establishing a connection with the server 34. 
[0071 ] The processor 74 may not include a JAVA® vir- 
tual machine but may execute native machine code. 



Claims 

1 . A transaction network (30 or 60) comprising a serv- 
er (34) and at least one terminal (50 or 62), each 

5 terminal (50 or 62) having a plurality of peripherals 
(52 or 64), the network being characterised in that 
the server (34) is arranged to store software for the 
peripherals (52 or 64), and communication links 
(33,54,55 or 71) are provided from the server (34) 

10 to each peripheral (52 or 64), whereby each periph- 
eral (52 or 64) is operable to download software 
from the server (34). 

2. A transaction network according to claim 1, where 
15 each peripheral (52 or 64) is operable to configure 

itself using the downloaded software. 

3. A transaction network according to claim 1 or claim 
2, where the software stored on the server (34) in- 

20 eludes application software and peripheral driver 
software. 

4. A transaction network according to any preceding 
claim, where each peripheral (52 or 64) includes an 

25 embedded processor (74) which operates with the 
communication links (71) to download software 
from the server (34). 

5. A transaction network according to claim 4, where 
30 each peripheral (52 or 64) includes hardware con- 
trol means (76) for controlling the hardware of the 
peripheral (52 or 64), and the embedded processor 
(74) operates the hardware control means (76) in a 
manner determined by the downloaded software. 

35 

6. A transaction network according to any preceding 
claim, where each peripheral (52 or 64) has a non- 
volatile memory (82) for storing boot-up informa- 
tion, whereby, on powering the peripheral (52 or 64), 

^0 the contents of the non-volatile memory (82) may 
be used for initialising the peripheral (52 or 64). 

7. A transaction network according to any preceding 
claim, where the peripherals (52 or 64) communi- 

45 cate with the server (34) using the TCP/IP protocol. 

8. A transaction network according to any preceding 
claim, where the communication links (33,54,55 or 
71) also enable the peripherals (52 or 64) of a ter- 

50 minal (50 or 62) to communicate with each other. 

9. A transaction network according to any preceding 
claim, where the peripherals (52 or 64) are selected 
from the following peripherals, namely: a user inter- 
ns face (64d), a card reader (64a), a receipt printer 

(64b) and a cash dispenser (64c). 

10. A transaction network according to any preceding 
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claim, where an information database (12) is in 
communication with the server (34). 

11. A transaction network according to any preceding 
claim, where the communication links (33,54,55 or 5 
71) include a router for concentrating information 
from the peripherals and transmitting that informa- 
tion across a single connection. 

12. A transaction terminal (50 or 62) having a plurality 10 
of peripherals (52 or 64), the terminal being charac- 
terised in that each peripheral (52 or 64) has com- 
munication hardware (54 or 66) for connecting to a 
server (34), whereby, in use, each peripheral (52 or 

64) is operable independently to access the server is 
(34) and to download software therefrom. 

1 3. A transaction terminal according to claim 1 2, where 
the peripheral communication hardware (54 or 66) 

is an ethernet card. 20 

14. A transaction network system comprising a server 
(34) and at least one terminal (50 or 62), each ter- 
minal (50 or 62) containing a plurality of peripherals 

(52 or 64), the network system be[ng characterised 25 
in that the server (34) is arranged to store a plurality 
of independent software modules, where at least 
one software module is associated with each pe- 
ripheral (52 or 64), and communication links 
(33,54,55 or 71 ) are provided from the server (34) 30 
to each peripheral (52 or 64), whereby each periph- 
eral (52 or 64) is operable to download one or more 
of the independent software modules from the serv- 
er (34) and to configure itself using the one or more 
downloaded software modules. 35 

15. A transaction network system comprising a server 
(34) and at least one terminal (50 or 62), each ter- 
minal containing a plurality of peripherals(52 or 64), 

the network system being characterised in that the 40 
server (34) is arranged to store a plurality of inde- 
pendent software modules, where at least one soft- 
ware module is associated with each peripheral (52 
or 64), and communication links (33,54,55 or 71) 
are provided from the server (34) to each peripher- 45 
al, wherein the server (34) is operable to reset the 
peripherals (52 or 64) and download software mod- 
ules to the peripherals (52 or 64) after they power 
up. 
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Fig 1 (Prior Art) 14 
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